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ABSTRACT and CONTENTS 

This document specifies the operation of the file-naming com- 
ponent of the utility system. 
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I The Structure of File Names 

File names, like all other names, will be restricted in length 
and character set. A maximum length of 16 characters for the 
main name and 4 characters of type seem adequate. The char- 
acter set will be restricted to letters, digits, and a small 

• 

subset of non-alphanumeric ASCII graphics. Lower case letters 
will be converted to upper case. 

The structure of a file name is given by the following pro- 
ductions . 

filemame = [access:key:name *:» ] name: spec 

name : spec = [userrspec] mainmame [ V V type] 
access :key: name = [user: spec] * v )>" main: name 

user: spec ='^# // user : number : / v )' user: name v ' : 

main: name = name / xu name 
type ~ name 
user: name = name 

user: number = 1$ digit 

name = ichars [word] $ (*-"word) 
word = achar $ achar 

ichars = letter / * f / * *" / */'' / *?'' 
achar = ichar / digit 

The system will adopt the following policies with respect to 
the use of file types, both in the name string and in the 
name look-up call. If the type is given in the name: spec, 
then the file corresponding to the name: spec will be opened 
or created for output calls. Otherwise, the type in the call 
will be used to complete the name: spec, if that type is sup- 
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plied. And if no type is specified in either the string or 
call, there must be only one file with the designated main: 
name in the file directors (MIB) . The file type for the se- 
lected file will be returned when the name is collected. 

When a file: name is collected, only the main: names may be 
abbreviated. User: names, account: names, and types must be 
given in full. The abbreviation look-up is described in 
section 4. The main: name may be surrounded with double quotes 
if a new name is desired. In any case a quoted name suppresses 
the abbreviation mechanism. 
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II Structure_of _File Types 

The following proposal for a system type -structure will be 
implemented. We assume the existence of a set of pre-known 
file types including: symbolic (S), language symbolic (LS) , 
symbolic data (DS) , binary data (DB), binary program (LB), etc 
We also assume the existence of an arbitrary set of user-de- 
fined and processor-defined file types, for example, FORTRAN 
symbolic (FTS) and FORTRAN (binary) program (FTB) . We would 
then have the type-structures: 

FTS. .,, ... FTB ... ... 

f/ \|/ \ // \l/ 

LS DS X LB DB 



Let us contrast the operations of a text editor, a FORTRAN 
Compiler, and a user program, with respect to the type-struc- 
ture. The editor would supply the type S when requesting file 
name look-up and would accept any file with type FTS, LS, DS, 
or S. The compiler would supply type FTS and thus exclude 
type FTB. The user program would ask for files of type DS or 
some sub-type excluding types LS, and S. Commands to create 
and modify the type structure are discussed in later sections. 

The initial system will have no type structure. 
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III File Commands 
The commands for maintaining a user's file directory (MIB) are 
invoked in one of two ways. First as commands to the FILE- 
MAINTENANCE subsystem. This subsystem contains all commands 
for manipulating the file directory. Secondly, those com- 
mands which are frequently used also exist as ordinary l * Top- 
Level* ones. We first describe the commands in the FILE- 
MAINTENANCE - subsystem. 

Commands preceeded with + will not be initially implemented. 

General 

+ ^>USER user: spec 

This command causes the maintenance program to work on 

the specified directory. 
> FINISHED 

returns from the maintenance program 
+ ^CREATE TYPE namei name 2 

The first type-name is made a sub-category of the second 

name. 
+ y DELETE TYPE name 

This command deletes the specified file type. 

Files 

For all commands in this category, wherever >v file-name" ap- 
pears, the following convention applies: If either the main- 
name or type is x *'' , then the command is repeated for all 
files which match the rest of the name. The four possibili- 
ties are: 



bee 



p/c-n.r 

FNS/W-4 



page 



name- spec 

* . * or * 

* : S 

SOME : * or SOME 
SOME:S 



meaning 

all files 

all type S files 

all files SOME 

the file SOME:S 



^DELETE FILE file-name 

If the user executing the command has owner access to the 
file, it is deleted. If the name refers to a link or 
access-key, it is deleted also. Processes may not be 
deleted. If the file-name uses the asterisk convention, 
the system will ask for confirmation before proceeding. 

> RENAME filemamei file:name2 

The name of the object designated by filetname]^ is changed 

to file:name2« 
)>CREATE LINK file:name]_ file:name2 

Establishes the first name as a link to (synonym for) the 

second one. 
^DELETE LINK file: name 

Deletes the link, not the file for which it stands. 
>LIST ALL 

Prints the entire MIB contents. 
>LIST CO-USERS 

Prints the names of all 'friends' and the degree of ac- 
cess to the MIB . 
> LIST-LINKS 
>LIST-PROCESSES 
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+ > LIST-KEYS 

Print the corresponding entries. 
+ >LIST TYPE -STRUCTURE 

Prints the complete type structure . 

>LIST FILE file-name option 

This command lists each designated file-name plus the in- 
formation specified by the option. If no option is given, 
only the name is printed. 
The options are: 
BRIEF which prints the name, 
ACCESS which gives the access fields, 
LENGTH which prints the current length, 
TIME which lists the time the file was last opened and 
the time it was last modified, or 
ENTRY which combines all of the above. 

>SET PUBLIC-ACCESS file: name access: code 

>SET CO-USER-ACCESS file: name access: code 

^SET OWNER-ACCESS file: name access: code 
+ ^>SET KEY-ACCESS file: name access: code key: spec 

These commands set the specified access field of the appro- 
priate file(s) to the access-code. The access code may be 
NO (none), RO (read-only), RW (read-write (, PX (proprietary 
execution), or OW (owner read/write) or a numeric value. 
The key-spec may be ## access-key-value, an access-key- 
name, or a user-spec. Setting KEY-ACCESS to NO causes the 
key to be removed from the access list. 
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Co -Users 

^CREATE CO-USER user: spec access: code 

Causes the user: spec to be added to the friend list if 

necessary and the access code to be set. 
^DELETE CO-USER user: spec 

Removes a friend list entry. 

Access Keys 

+ >GET-KEY file:name-j_ file:name 2 

The second file-name, which must be the name of an access- 
key, is copied to the current MIB as name^ . 

+ ]>CREATE KEY file: name 

The name is used to create a new access-key. 

+ ^DELETE KEY file: name 

Removes the access key from the MIB. 

Top-Level Commands 

The following commands will be equivalent to typing: 
©FILE -MAINTENANCE 
)sorae command 
> FINISHED 
The table gives the top-level name and the corresponding sub- 
command . 

Top-Level Sub-Command 

LIST-FILE LIST FILE 

DELETE-FILE DELETE FILE 

RENAME -FILE RENAME 
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Following the top-level name the user should type the same 
parameters required for the corresponding sub-command. For 
example 

©LIST-FILE PROGRAM:* ENTRY 
is equivalent to: 

©FILE -MAINTENANCE 

>LIST FILE PROGRAM:* ENTRY 



> FINISHED 
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IV The Abbreviation Scan 

The main: name can be abbreviated to an arbitrary degree as 
long as the input string is unambiguous. The precise defini- 
tion of ambiguity is somewhat complex. However typing the ex- 
act name always works, whether or not the name is quoted. We 
wish to emphasize the point that the abbreviation scan is ap- 
plied only to main: names, not to user: names, account: names, 
or types. 

A name consists of a number of words separated by hyphens. We 
first consider the case of single-word names. If a directory 
contains the names: 

LONG 

LIST 

LISTING, 
then LO," r LIST, and " LISTI respectively are the shortest 
abbreviations. In particular " L, *LI, and LIS matches a 
name if the input is identical to the initial characters of 
the name. Thus ''l," 'LO," "LON," and' LONG " all match LONG '; 
no other strings do. We also distinguish between partial and 
exact matches. 

The abbreviation-scan algorithm for single-word names is this: 

1) Scan the directory until a name is found which the 
input string matches. If no name is matched, return 
an error . 

2) If the input exactly matches the name, return this 
entry. Otherwise remember this entry. 
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3) Continue scanning until another match occurs. If no 
other match occurs, return the entry saved in step 2. 

4) If in the previous step we find an exact match, return 
it. Otherwise the name is ambiguous. 

Applying this algorithm to the example above yields the mini- 
mal abbreviations listed there. 

We now generalize this algorithm to include multi-word names. 
An input string matches a name if each (partial) word of the 
input matches the initial words of the name. Note that the 
name may contain more words than appear in the input string. 
Thus in the directory: 

LIST-FILE 

LAB -PROGRAM, 
vV Ll' and U LA" match only one entry. Also note that L-F ' and 
*L-P" also match a unique entry. The algorithm stated above 
will work with the generalized definition of match, however it 
is slightly restrictive. For example to match: 

LIST-FILE 

LIST-FILES, 
would require that the input string be exact, whereas L-FILE 
and L-FILES should be adequate abbreviations. 

The following algorithm eliminates the restriction stated 
above. It uses the general definition of match. 

1) Scan the directory until a name is found which is 

matched by the input. If no name is found, return an 
error. Otherwise save the entry and mark it unam- 
biguous. 
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2) Continue scanning until another match occurs. Return 
either the saved entry if it is unambiguous or an 
error . 

3) If two entries (the current and saved ones) are found 
which are matched by the input, determine which is a 
more complete match. This decision is made by com- 
paring each word of both entries with the (partial) 
words of the input. If we find an input word which 
exactly matches one, but not both, of the corres- 
ponding words of the current and saved entries, we 
choose the entry which has the exact match and return 
to step 2 (the new choice is unambiguous) . Otherwise we 
mark the saved entry ambiguous and return to step 2 . 

This algorithm has the following desirable properties: 

1) If the input is identical with some entry in a direc- 
tory, that entry will be returned. 

2) Unambiguous abbreviation is allowed. 

3) The algorithm can be implemented by examining each 
entry only once, as opposed to a multiple scan tech- 
nique . This allows several directories to be chained 
together . 



